========================================================================= INFO-ATARI16 Digest Tue, 23 Jan 90 Volume 90 : Issue 86 Today's Topics: ARC 6.02 bugs dissassembly GNU/Sozobon C question Mac ROMS Need Hard Disk Wisdom writing "tee" for the ST ---------------------------------------------------------------------- Date: 22 Jan 90 21:17:19 GMT From: ucsdhub!hp-sdd!hp-pcd!hplsla!andyc@ucsd.edu (Andy Cassino) Subject: ARC 6.02 bugs Message-ID: <5440098@hplsla.HP.COM> | | It turns out that I can not get ARC 6.02 to work with any of the graphical | shells I have for ARC (ARCSHELL, ARCGSH21, UNARC). All of them produce either | two or four bombs (it keeps changing) when they go to execute ARC. The older | version of ARC (v5.21b I think) runs fine with all of these shells. | | Has anyone else had trouble with ARC V6.02 running under these shells? I | assume it is working for most people since no one else has mentioned the | problem. | | ---------- I'm using ARCSHELL 2.1 with ARC 6.02 with no trouble under TOS 1.4. There is supposed to be ARCSHELL 2.1b out now to rectify some bug or another with ARC 6.02, but I haven't seen the bug nor do I have v2.1b.... Disclaimer: The opinions expressed herein are those solely of the author, who has no pecuniary interest in the companies, products, or publications mentioned above. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Andy Cassino % % uucp: hplabs!hplsla!andyc domain: andyc%hplsla@hplabs.hp.com % % Hewlett-Packard Lake Stevens Instrument Division % % 8600 Soper Hill Road Everett, WA 98205-1298 % % (206) 335-2211 % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ------------------------------ Date: 23 Jan 90 17:04:23 GMT From: voder!pyramid!athertn!alex@ucbvax.Berkeley.EDU (Alex Leavens) Subject: dissassembly Message-ID: <17035@laurel.athertn.Atherton.COM> Daniel Glasser writes: >In my honest opinion, biased as it may be, the MWC manual is the single >best volume for programming the ST published to date. It needs revision, >bugfixing, and maybe some other tweeking (new GEM examples, etc.) and >the compiler should be updated, but it is still a very good package at a >good price. Seconded. Whenever I'm writing GEM code, the first thing I look in is the MW manual. If I can't find it there, I look in the HitchHiker's Guide, or somewhere else. But I can usually find it in MW. It's really good. -- |-------------------------------------------------------------------------| |--alex | alex@Atherton.COM | Caution! Falling Opinions, next 6 miles | | Now who are you gonna believe--me, or your own lyin' eyes? | |-------------------------------------------------------------------------| ------------------------------ Date: 23 Jan 90 19:34:36 GMT From: zaphod.mps.ohio-state.edu!uwm.edu!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!w atserv1!watdragon!tiger!swklassen@tut.cis.ohio-state.edu (Steven W. Klassen) Subject: GNU/Sozobon C question Message-ID: <20086@watdragon.waterloo.edu> In article <894@per2.UUCP> dag@per2.UUCP (Daniel A. Glasser) writes: >A large part of the speed "problems" that the MWC compiler has is because of >this history. A version (built from the same sources) ran on a PDP-11 as >a cross compiler until version 3. The PDP-11 has only 64k of virtual >address space. The compiler, therefore, uses disk files to store intermediate >code and chains between programs to do various stages of compilation. >The advantage to this is that the MWC compiler can run effectively in systems >with limited memory (512k with DAs loaded) and can handle programs larger than >available memory. I've linked an 800k program on a 520 with MWC. The speed problem can be minimized through the use of the ram-disk (if you have the memory for it - ie. at least a 1040). A very nice ram disk is included in the MWC package. The 'disk' files used for intermediate code and stuff are then written in the ram disk, ie. almost as fast as using main memory directly (there may be some overhead in the maintenance of the ram disk but it likely isn't too bad). Multiple passes through the data is very slow on a disk but not bad at all on a ram disk. I must admit, however, that I haven't made any comparisons between compile speed of different compilers. I consider that issue to be of lower priority than run speed (ie. I will put up with slower compile times if I get better run times as a result.). Steven W. Klassen +-----------------------------+ Computer Science Major | Support the poor...buy fur! | University of Waterloo +-----------------------------+ ------------------------------ Date: 22 Jan 90 16:56:07 GMT From: njsmu!telesci!cciolori@princeton.edu (Christopher Ciolorito) Subject: Mac ROMS Message-ID: <938@telesci.UUCP> Perhaps this is a silly question, but I will ask it anyway. Everyone knows that the ST can mimic the Mac with the right hardware, software, and of course the Mac ROMS. In addition, a message had been posted which indicated that the new TT machine would allow the ST to run Mac software at high speed, which could give apple some stiff competition if Atari took advan- tage of this, and made the public aware that this software/hardware exists. A great ad campaign would tell potential buyers that the Atari, in addition to running its own software, could also run IBM, and Mac stuff too! ....then I got to thinking...let's say that Atari did begin take advantage of this oppurtunity, and in fact were hurting Mac II sales. Couldn't Apple just say FORGET IT and NO LONGER SELL anyone Mac ROMs? Or would it be more profitable to allow Atarians to continue to buy them? I mean, they are making money when people buy them, although I am sure they would rather be selling THIER computers along with them. Just a thought...what does everyone think? Chris ------------------------------ Date: Tue, 23 Jan 90 10:27:54 -0900 From: Subject: Need Hard Disk Wisdom In <7500012@m.cs.uiuc.edu>, totty@cs.uiuc.edu writes: > I'm sure this subject has been covered many times, but I > haven't been reading this group for a long time. I am > interested in obtaining info from anyone about building > hard disks fro the ST. Advice on interfacing, drive/controller > recommendations, power supply choices, cases, and difficulties > about the ST. Please email to me if the subject has been beaten > to death. Not beaten to death recently, I think. I've built three 60 MB drives using the BMS-200 kits from E. Arthur Brown. EABCo sells the BMS host adapter, case, and power supply...you buy the drive elsewhere. I bought ST-277N drives from Hard Drives International (they advertise in Computer Shopper and Byte). It takes less than an hour to put the drive together and install it, if you follow EABCo's somewhat sparse instructions correctly. Construction consists of attaching the DMA cable, a ribbon cable, two power supply connectors, and mounting the drive and host adapter in the case. The BMS software has a nice boot-holdoff feature that waits until the drive spins up before starting the boot process, so you don't have to power up the drive and ST separately. Other than that, the BMS software is pretty basic. There's a battery-backed clock on the host adapter which can be read from a program in the auto folder. Some considerations: 1. The cost of everything plus shipping is much cheaper than comparable drives from Supra or Atari, but there are other options, such as ICD and Toad Systems, which are in the same price range as BMS. 2. Two of the drives worked fine the first time, but a third had a flakey hard drive which sort of worked for a few weeks, then died. HDI replaced it, but I found arranging the replacement very annoying. Calling HDI's support line seems to involve a mandatory wait of 20-30 minutes on hold, and it isn't an 800 number. It also took them a month to come up with a replacement, compared to two days to ship the original. In contrast, both EABCo and BMS were very helpful and responsive in diagnosing the problem. 3. The BMS software is very basic, limited to 4 partitions @ 16 MB. The EABCo version simplifies the BMS package by supplying special setup programs for Seagate SCSI drives ONLY; they omit "confusing" information about setting up other types of drives. If you want to use another brand of drive, you should buy the BMS-200 directly from BMS. BMS suggests using Atari's hard disk software if you want bigger or more partitions... apparently they aren't planning to support those options anytime soon. 4. With the EABCo setup, there is a spare power supply connection. You should be able to add a second SCSI hard drive for the price of the drive, a SCSI ribbon cable, and a second case (no room in the first case due to the host adapter). How you could get the power and SCSI cables to the second drive is left as an exercise for the ambitious. The main advantage of the SCSI solution is ease of upgrade. You can buy a small SCSI drive and replace it with a big one later, and you have a good chance of selling the original in the pc/mac marketplace. I think that the BMS system from EABCo is a reasonable choice, particularly if you enjoy tinkering, but check out ICD and Toad options as well. Good luck, Don Rice FNDDR@ALASKA.bitnet Notes: EABCo = E Arthur Brown Co, 612-762-8847 BMS = Berkeley Micro Systems, 415-547-2191 HDI = Hard Drives International, 800-234-DISK ICD, Toad: look them up in your favorite ST mag ------------------------------ Date: 23 Jan 90 18:08:06 GMT From: mcgill-vision!quiche!calvin!depeche@BLOOM-BEACON.MIT.EDU (Sam Alan EZUST) Subject: writing "tee" for the ST Message-ID: <2027@calvin.cs.mcgill.ca> I asked this question a little while ago and got some responses from people who had good intentions but not enough facts about how to solve the problem... How hard could it be to get a program to send all its output to the a file or the printer WITHOUT changing the screen output? i.e. I'd like to direct output to a file but I also want to see what it is on the screen, so I can run interactive programs and save all the output. This would be easy if there was a shell which supported pipes, but contrary to popular belief, GULAM does not support such, and neither does mwc shell (it simply redirects the output of one program until it is finished, and then runs the second taking the file it created before and redirects the input of it to this file.) A real pipe needs multitasking, I guess. Do standard output calls use a system call to print characters on the screen? if so , perhaps changing the vector for that call to another routine which first sends the character to the printer and then calls the original system call would do the trick. I am a novice in this area of system programming - I only know the theory. Has anyone actually done something like this? -- S. Alan Ezust depeche@calvin.cs.mcgill.ca McGill University School of Computer Science - Montreal, Quebec, Canada If pro is the opposite of con, what's the opposite of progress? ------------------------------ End of INFO-ATARI16 Digest V90 Issue #86 ****************************************